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^BSTSACT 



This thesis provides a student of Conunand and Control with a 
computer simulation of a simple Command and Control (C2) 
model. The simulation is a user-friendly, interactive 
proqram with multi-colored, high-resolution graphical 
displays to illustrate the effect of C2 on a stylized, 
simple, combat situation. A User's Manual is provided to 
facilitate the use of the simulation. 
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I, IN TRODOCT IOa 



There are maty ccmbat simulations available at. r,he Naval 
Postgraduate School, but few, if any, have a Command and 
Control (C2) system as an integral part of the simulation. 
Those computer simulations which do employ a C2 system are 
often complicated and difficult to analyze. The purpose o;: 
this thesis is to develop a simple C2 model, and a simula- 
tion of the model, to demonstrate the effect of a Command 
and Control s ysr em on a stylized, simple, ccmbat situation. 

A highly user-friendly, interactive computer simulatior 
is used to graphically illustrate the effect of C2 on 
combat. To enhance the interactive aspects of ohe simula- 
tion, a RAHTEK 9 UOO color graphics system having a high 
resoluticn graphics capability is used to display intermed- 
iate and end-of- tattle results. All of the program's input 
variables are explained during rhe simulation sc that once a 
user starts the program, he does not need a user's manual, 
although one is provided. 

It is hoped that use of this simulation will provide a 
user with insights into the effect of C2 upon the outcome of 
conflicts. The user, by varying the amount of C2 and 



9 



counter C2 used curing a particular battle, should com=> to 
understand and a fpreciate the importance of C2, and how C2 
decisions can easily change the outcome of a battle. 

This paper explains a simple C2 model and how the model 
is implemented it a computer simulation. The antrition and 
movement of forces are also explained to aid the user in 
understanding the combat portion of the simulation. 
Photograghs are provided to illustrate both the input and 
output of the program. Finally, a user's manual (Appendix 
A) is provided. The user's manual provides the documenta- 
tion needed to run the program and to add new subroutines to 
enhance the computer simulation. 
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II- IHB_SIMDLATI0N 

A. GEKEBAL 

Th<= simulation uses a computer generated, color graphics 
playing board which represents a section of land. The board 
is divided into spaces (called hexes) in order to position 
the playing pieces and to regulate their movement. The 
playing pieces called units are made up of Red and Blue 
forces. The stylized scenario pits a Blue defending force 
against an advancing Red force. At the beginning of the 
simulation.- the user initializes all of the input variables* 
values (approximately UO), dexermines the route the Red 
units will move along in their axtack, on the Blue units and 
then starts the conflict. At the end of xhe conflict, the 
user can display the battle results in a Force vs Time 
graph. After examining the end-of-ba ttle results, the user 
may run the simulation again with the same initial values 
for all the variables, or changes may be made to any vari- 
able desired. The user can then run the simulation to 
determine if the outcome of the conflict would have changed 
as a result of changes in the initial value of the 
variables. 
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B. THE PLAYING HOARD 



The computer generated, biqh-resolution color graphics 
playina board represents a piece of ground. It is divided 
into 68 hexes to regulate the movement and location of the 
units. There are three types of hexes shown on the board 
(see Figure 2.1) . Hexes 26 ,33, 37, 56, and 63 are green in 
color and represent forest, or wcods. Hexes 17, 32, and 45 
are magenta and represent towns or cities. The remaining 
hexes are yellow and represent ordinary land (fields). 

In the present version of the simulation the cities and 
forests have no effect on the forces or the simulation 
results. However, it is envisioned that combat situations 
could be developed incorporating these features to allow the 
user to explore the effect of these features on command and 
control. 

C, THE PLAYING IIECES 

There are twc types of forces. Red and Blue, used in the 
simulation. The Blue forces which can be composed of three 
types of units (see Figure 2.1) 

♦Blue unaimec units represented on the board by the blue 
letter 0, 
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♦Blue sensor-aimed units represented on the board by the 
blue letter A, and 

♦ Blue command and control outposts represented on t. he 
board by the blue letters BC. 

The Red forces, cn the other hand, can be divided into two 
types of units (see Figure 2.1) 

♦Red Main units represented on the board by the red 
letter M, and 

♦Red counter-command and control units represented on 
the board by the red letter C. 

The letters representing the different units can nave 
any of five different sizes during the coarse of the battle. 
At the beginning of the simulation all the letters, except 
for the blue letter A, are full-sized, indicating the unros 
are at full strength. As the unit's strength is depleted 
(thru attrition) by decrements of 20% of the initial unit 
strength, the size of the letter decreases. Thus in Figure 
2.1, the red letter C indicates that the Red counter-command 
and control unit has lost over 40% of its initial strength 
while the blue letter U indicates that the Blue unaimed unit 
has lost over 80% of its initial strength. 
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Figure 2. 1 



The 



Playing Board Layout. 
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The blue letter A is the only exception. At the begin- 
ning of the simulation, there are no Blue sensor-aimed 
units. See Chapter IV for an explanation of why there are 
no Blue seasor-ained units, and how to transform Blue 
unaimed tc Blue s€'nsor-aime d units. As the conflict 
progresses and Blue unaimed units are transformed into Blue 
sensor-aimed ’-mits, the size of the blue letter A increases. 
The letter A becomes the next larger size when the Blue 
sensor-aimed unit tjains 20% of the Blue unairaed units' 
initial strength. Also note, that as the Red units fire on 
the Blue sensor- ciued units, the letter A decreases in size 
because of attrition. 

t 

D. SEQOERCE OF ELAY 

The simulation is made up of four phases each of which 
the user is an irtegral part. The four phases are 

(1) . The user input 

(2) . Selection of the Red Forces' route of attack 

<3) . The ccrflict simulation 

(4) . After-tattle analysis 

1 . T he Ose r Input 

The first step in simulating the conflict is to 
initialize all of the program's variables. To do this the 
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user is presentee a ocenu on the BAHTEK graphics display 
titled 'Table of Variables and Current Values' (see Figure 
2,2) in which ail the variables have been initialized with 
default values. During this phase, the user can change any 
variable's initial value. To change a value of a variable, 
or to obtain an explanation of the meaning of a variable, 
the user enters the variable's line number on rhe BAHTEK' s 
keyboard and presses the return key. For example, if the 
user desires to change the hand-to-hand combat range, he 
enters the number 6 ctnd presses rhe return key. The expla- 
nation of rhe variab]e hand-to-hand combat range is then 
displayed on the screen (see Fiaure 2.3), The user may 
change the hand-to-hand combat range by entering a new 
range, or he can elect to leave the range at its current 
value by simply pressing the* return key without pressing any 
other key. 

At the beginning of the simulation, all the varia- 
bles have initial values. If the user changes the value of 
a variable, rhen that value becomes the default value for 
all the remaining simulation runs for the session. This 
capability allows the user to incrementally change a vari- 
able, determine its impact on the outcome of the battle, and 
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Figure 2. 2 



Table of Variables and Current Values. 
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then change the value of another variable and not have to 
re-enter all the previous changes which the user had made. 

After all the variables have been initialized, the 
user enters 99 and the second phase of the simulation is 
entered. 

2 • S electi o n of the R e d Fo r ce s* Route of Attack 

The second phase of the simulation is determining 
the Red force's route of attack. In the present version of 
the simulation, only the Red force i.s allowed to move. 
Therefore, the user must plan a Red route of attack and 
enter it in the computer. This is simplified for the user 
through the use cf the trackball. The user designates all 
turning points bj moving the trackball cursor to the hex 
where the turninc point is to occur and depressing the enter 
key on the trackball. (The Red fores travels in a straight 
line from turninc point to turning point.) When the user 
has entered the desired path of the Red force, the cursor is 
then moved into the red area at the bottom cf the screen and 
the enter key on the trackbal.l depressed. (See Figure 2.4) 
At this time, the program automatically finds the location 
of the closest Blue Main force and ensures the Red unit will 
move from the final turning point to within hand-to-hand 
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combat range of the Blue Main force. (This feature ensures 
the battle will terminate.) 

Figure 2.4 shows two black circles drawn on rhe 
playing board with a BC outpost at each circle's canter. 

The circle represents the approximate sensor range for the 
BC outpcst at -its center. If the Red force enters the 
circle during its attack, the BC outpost will sense the 
presence of the Bed force and this will allow some of the 
Blue unaimed (relatively ineffective) units to be trans- 
formed into Blue sensor-aimed (relatively effective) units. 
Therefore, the Red force should attempt to stay outside of 

the BC sensor range or to travel on the fringe of the black 

♦ 

circle to lessen the effect of the BC on the outcome of the 
conflict. 

Once the route of attack has been selected and 
entered into the computer, the battle simulation (phase 
three) begins. 

3 . Ph a se T h ree 

During phase three of the simulation, the Red units 
attack and the Blue units retaliate. As the battle 
progresses, the computer-generated color displays of the 
battlefield show the letters representing the different 
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units reducing in size as the units are depleted. Also, ir 
shows the Red unit’s letters moving across the playing 
board. 

In this phase, the user has an opportunity to 
examine four status reports. The Red and Blue Force Status 
reports (Figures 2.5 and 2.6) give the exact location of 
each force and the strengths for each unit type as well as 
the total strength for each force. Figure 2.7 shows the 
Blue Sensor Outpcst Status report which provides the user 
with the number cf assets remaining at each BC outpost. 
Figure 2.8 displays the ranges between all the forces 
involved in the conflict. The user may examine any status 
report by placing the trackball cursor over the letters of 
the status report he wants to examine and depressing the 
enter key. For example, the user could examine the Blue 
Force Status report by placing the cursor over the word 
’’BLUE” at the bottom of the screen and depressing the enter 
key. When the user places the cursor over the letters 
•’MODEL", the next game step of the simulation is displayed. 

The displays provided during this phase of the simu- 
lation allow the user to visualize what is taking place on 
the battlefield. For example, the user can determine if a 
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unit is being filed upon by more than one opposing unit or 
if a unit is dividing its firepower among all targets of 
opportunity. The battle displays provide the user with 
pictorial representations of the battle instead of columns 
of numbers in a ^rinrout. 

When the force strengths of all the Red units^ or 
all the Blue fighting units., are equal to zero (ie, one 
force has won the battle by annihilating the other) then the 
user enters phase four of the simulation by placing the 
cursor over the letters '’MODEL” and depressing the enter 
key . 

^ • A fter-B a ttle Ana lysis 

The final phase of the simulation is the Force vs 
Time graph. (See Figures 2.9 and 2.10) This graph allows 
the user zo plot the forqe strength vs time of all the units 
involved in the tattle. It also plots the break points (a 
user input) on rhe total, force strength line (RT1, RT2, BTI, 
BT2 , and 5T5) , total force strength line is the sum of 
the units which form the force. For example, RT1 is the sum 
of RM1 and RCC1 , while BT1 is the sum of BUI and BAI. This 
allows the user to hypothesize than the outcome would have 
been different had the units retreated at their respective 
break points. 
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Figures 2.9 and 2.10 are examples cf graphs the user 
can examine. The plotted lines are color coded and have 
letters spaced along them to aid the user in determining 
which line is associated with which force. The Red forces 
all have red lines, the Blue Main forces have blue lines and 
the BC outposts have black lines. The letter associated 
with each line is shewn in the blue menu area an ths bottom 
of the figure. For example, the Red force's total strength 
line, RT1, has tie red letter A spaced along it, while the 
Blue force's total strength line, BMI , has the blue letter G 
spaced along it. 

It should be noted by the user that there is a 
maximum of 50 data points per line that car. be plJtrei by 
this routine. Therefore, if a battle simulation has nore 
than 50 game steps, only the first 50 data points will be 
plotted. 

The user selects the unit to plot by placing the 
trackball cursor over the letters representing rhe unit, and 
depressing the enter key. If the user wishes to clear the 
screen and replot the forces, then place the cursor over the 
words "NEW PLOT" and depress the enter key. To terminate 
this phase of the simulation, the user places the cursor 
over the letters "RETURN" and depresses the enter key. 
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At this point in the simulation the user can either 
return to phase cne and start another simulation, or ezir 
the program. If the user returns to phase one, all the 

variables are initialized to the values of the last simula- 
tion run and the user may again change any value of any 

variable. Also, the user may use the same route of aztack 

as the previous simulation, or may enter a new attack route. 
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Figure 2.5 Ccmbat Siaulation Showing Red Force Status, 
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Figure 2.6 Coabat Simulation Showing Blue Force Status. 
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Figure 2.7 Coibat Simulation Showing BC Outpost Status, 
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Figure 2.8 Comtat Simulation Showing Range Between Forces, 
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Figure 2.10 Example 2 of a Force Strength vs Time Plot 
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III. a_SIMPLE_C2_MCDEL 

This section of the paper will provide the user with a 
very basic explanation of a C2 model and describe the func- 
tions of the C2 process. The simulation attempts to 
incorporate all the functions of the C2 process and ir c.Iso 
tries to capture the time dependence of the C2 information 
in a combat situation. 

The primary goal of any C2 system is to control a 
hostile environment. To control the environment means 
either to maintain the status quo between forces, or to 
obtain a more advantageous position, or to bring about a 
successful concltsion to a confrontation or battle. In this 
computer simulation, the goal of the Blue C2 is to bring 
about a successful conclusion of a battle with the smallest 
loss of assets possible. 

The C2 process is depicted in Figure 3.1. For a C2 
system tc be effective in controlling its environment, it 
must first be ab3e tc sense its surroundings and then 
process the sensed data and compare these results with the 
desired state of the envirnoment. After the comparison is 
made, a C2 systeir must be able to decide on courses of 
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action tending tc make the sensed state of the environment 
and the desired state of the environment the same. Finally, 
a C2 system must choose a course of action for its forces to 
follow to achieve it's goal, ie, to bring the sensed state 
of the environment close to the desired state of the 
env ironment . 




Figure 3.1 The C2 Process. 

Not explicitly shewn in Figure 3.1, but an integral part 
of the C2 system, is the time component for each function of 
the C2 process. If the C2 system can nor bring its forces 
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to bear on the ervircnment in a timely manner, then the 
battle may be lost before its forces have a chance to act. 

The times associated with each of the functions of the 
C2 process are shown in Figure 3.2, Ts is the time required 
to sense the initiated hostile action. It will next take a 
tine, Tp, to process the sensed data and to pass the 
processed data tc the comparision function where time Tc is 
required to evaluate the data and pass it to the decision 
function. The decision function will need a time Td to 
reach a decision and time, Ta, will be taken tc prepare a 
course of action and pass this choice to the forces. 

Finally, the forces will need time, Tf, to implement the 

« 

orders given. Therefore, the total time, Tt, involved in 
the C2 process is 

Tt =: Ts + Tp + Tc + Td + Ta + Tf (3. 1) 

If one as su Lies e hostile action is initialed at time T1 
and at time T2 the hostile action will stop the C2 system 
from achieving its goal, then the sum of the times Tt asso- 
ciated with each function of the C2 process should be less 
than T2-T1 if the C2 system is to be successful. 
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2 PiTOcess. 
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IV. IM PLEME NTATION OF THE C2 MOD EL 

The previous section illustrated a very general and 
simple C2 system, and pointed out that time plays an impor- 
tant factor in the C2 process. For a computer program tc 
simulate the C2 process, it must represent both the C2 func- 
tions and the tine factor. This section will describe how 
the simulation presented in this thesis represents rhe C2 
process and some of the decisions which musr be made by tne 
user. It is important to note that a particular coinbar 
scenario is described here for illutration. The basic ideas 
of C2-affected combat, and the graphical display can, of 
course, be extended to describe a variety of other inter- 
esting situations. 



A. THE OPPOSING FORCES 



In the present specific 
opposing forces. Red forces 
attacks the Blue force with 
Blue fighting force to gain 
pied by Blue. The Blue for 
attempting to stop the Red 
terrain. 



scenario, there are two types of 
and Blue forces. The Red force 
the goal of annihilating the 
conrrol of the territory occu- 
ce, on the other hand, is 
force's advance into Blue's 
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The Blue force has the option of putting some of its 
resources into a C2 system. In the present scenario, the 
Blue C2 force converts "unaimed" (relatively ineffective) 
Blue forces into "aimed" (relatively effective) Blue forces; 
the latter wreaks greater attrition upon Red forces than the 
former. The Blue C2 system could give the Blue force a 
decisive edge during a battle depending on the decisions 
made by the Red force and how well the C2 system operates. 
Presently, the Blue force has no counter-command and control 
(C-C2) resources. 

The Red force, in the current simulation, has no 
explicit C2 assets but it does have at its disposal C-C2 
resources. These C-C2 resources can negate rhe C2 benefits 
of the Blue force. 

B. SIMOLATIRG TEE C2 PROCESS 

The Blue forces are composed of three types of units 

1) , Blue command control sensor outposts (BC) 

2) . Blue unaimed units (3U) and 

3) . Blue sensor-aimed units (BA) 

The first three function of the C2 process (ie, sensing, 
processing, and comparing) are performed by the Blue command 
and control sensor outpost (BQ . The BC outposts have no 
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fighting capability. They do have, however, sensors which 
can detect the approaching Red units. The BC sensors, as is 
true of all sensors, have a maximum detection range beyond 
which the Red units are undetectable. When the BC outposts 
do detect the fed units approaching, they process the data 
and send information to the Blue Main force (BM) which 
allows Blue unaiited units ( BU) to be transformed into Blue 
sensor-aimed units (BA). The BA units are then brought to 
bear upon the advancing Red units. 

An expression was developed which gives the maximum 
number of BH units to be transformed to BA unirs during each 
game step by eact BC outpost for each Blue fighring force. 

It expresses the maximum number of units as directly propor- 
tional 'CO the amcunt of resources allocated to the BC 
outpost and, directly proportional to the fracrion of time 
per game step than the BC outpost is turned on, ie, actively 
searching for approaching Red units. It also expresses the 
maximum number of units as being inversely proportional to 
the distance the BC outpost is from the approaching Red unit, 
it is reporting cn (the larger the distance, the less accu- 
rate the targetting information) and, inversely proportional 
to the distance the BC outpost is from the Blue fighting 
force it is sending its report to. 
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The maximum r.umber of BD units which can be transformed 



into BA units at each Blue Main fores by a single BC outpost 



in a game step is calculated using the following formula: 



BAMAX = TIMEOS * BC (4.1) 

1 + RNGBC + ENGBLn 
RITOT" “HUT — 



where 

BAMAX = maximum number of BU units that can be 
changed to BA units during a game step; 

TIMEON = the fraction of a game step during which 
the BC sensor is turned on; 

BC = the a nount of resources a 3C unir has 
available during a game step; 

RNGBC = th€ distance the Red force is from the 
reporting 3C unit; 

RNGBLD = the distance the Blue force is from the 
reporting BC unit; 

RDWT = the importance the user places on the distance 
the Red fores is from the BC unit; 

BWT = the importance the user places on the distance 
between the Blue force receiving the report 
and the reporting BC unit. 
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The value of the variables TIMEON, BC, RDWT, and B'4T are 
user supplied during the input phase of the simulAtion 
discussed in Chapter II. 

RDWT and BWT weight factors can be assigned a value 
between 1.0 and 10.0. A weight of 1.0 means the range 
between the BC octposT and the force (either Red or Blue) is 
the most important factor in the transformation of 3D units. 
A weight of 10.0 signifies that the range has little impact 
on the number of BD units which could be transformed. It 
should be noted that once all the BU units have been trans- 
formed to BA uni Is, the BC outposts do nothing further to 
aid the BM forces. 

In the present simulation, the BC outposts are consLd- 
ered to be networked together. Therefore, if a Red force 
enters the BC sensor range, the transformation of BD units 
to BA units occurs for all Blue Main forces. During the 
user input phase, the variable BWT is entered allowing the 
use to regulate the transformation rate at the Blue Main 
units based on data received from distant BC outposts. If a 
user places the EC outpost a large distance from a Blue Main 
force and determines that BWT is very important (ie, 1.0 or 
2.0) , then fewer BD units would be transformed to BA units 
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than if BHT was insignificant. Th® user should make a 
trade-off between early detection of approaching enemy 
forces and the nnmber of BO units transformed to BA unirs in 
each game step. 

Similarly, altering the variable RDWT allows the user to 
control the tran formation rate of BU units to BA units based 
on the distance the advancing Red force is from the BC 
outpost. Increasing the importance of the range from the 
Red force to BC cutpost means that the number of BU units 
transformed during a game step would be less if the Red 
force was on the fringe of the BC sensor range than if the 
Red force was directly on top of the BC outpost. 

The decision and action process of the C2 system are 
performed at the Blue Main (BM) force. The 3M force is 
composed of both BO and BA units. The mission of the BM 
force is to convert EU units to BA units. The goal of the 
Blue force is to have as many BA units as possible when 
fighting because the BA units have a much higher probability 
of kill than do the BU units. However, both the BA unit's 
probability of kill and the BU unit's probability of kill 
are user supplied values. Therefore, the effect of the BA 
units on the battle outcome depends on the initial values of 
the probability cf kill. 
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The number of 3U units which are actually changed to BA 
units at each Blue Main force is calculated using the 
following equaticn; 



BOCVT = BAMAX*(1 - exp ( -STEP/ (NBC*BTIME) ) ) (4.2) 

where 



BOCVT ~ th€ number of BU units converted to BA units 
at a Blue Main force 

BAMAX = the sum of equation (4.1) for all BC units 
reporti.ng to a Blue Main force. 

(There can be up to 6 BC units operating 
a t a t:.me) 

NEC = number of active 3C units during the game step 
(If EC = 0, then BOCVT = 0) 

BTIME = tine required by the Blue force to act on 
the hostile action taken by the Red force 
STEP = numter of minutes in a game step 
The value of the variables NBC, BTIME, and STEP are user 
supplied during the input phase of the simulation. (The 
user should be avare that equation (4.2) is valid only for a 
range of NBC between 0 and 6.) 

In Chapter III it was stated that time was a very impor- 
tant factor of a C2 system. Time is introduced into this 
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HTIME represents the 



simulation throuch the variable BTIME. 
time required for the Blue force commander to convert his 
unaimed units to senscr-aimed units. 3TIME is the sum of 
the time (ie, Tt of equation (3.1)i for each function of the 
C2 process. The larger rhe value of BTIME, the smaller the 
number of BU units which are transformed tc BA units during 
a time step. 

Equation (4. 2) also incorporates another important 
aspect of command and control into the simulation. That 
aspect is that mere command and control is not necessarily 
better than less command and control. The variable NBC in 
equation (4.2) (the number of active, reporting 3C outpost 
during a game step) can greatly influence the actual number 
of BU units converted to BA units a- each Blue Main force. 

It is assumed that as more BC outposts report to a BM head- 
quarters, it will take more time for the C2 system to 
process the reports, decide on the required action and 
communicate rhat course of action to the forces in the 
field. Therefore, as more BC outposts are added to the C2 
system, the system efficiency (ability to transform units) 
will decrease. (It should be noted that if Blue adds more 
BC outposts and EAHAX (from equation (4.1)) does not 
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increase, then this is a waste of valuable resources. Also, 
the Blue force ccmmander must still process whatever infer-" 
mation the additional BC outposts are sending to him, even 
if it does not help his fighting forces.) 

One way to make the C2 system more efficient is to 
lessen the amount of decision time (BTIME) required by the 
Blue force commander. If, fer each additional 3C outposr 
added to a C2 system, the time required to react to a 
hostile action is reduced, then the number of units trans- 
formed in equation (4.2) would increase. This could be 
accomplished if the user were to stipulate there was an 
information filtsr being used by the Blue force commander. 

Of course, the resources devoted to filtering infermarien 
should be at the expense of fighting units, ie, fewer 3U 
units at the start of the battle. 

A user has tc make a trade-off between the C2 system 
efficiency and ersuring the battlefield is covered by his 
sensors. If all avenues of approach by the Red force are 
covered by BC sensors, then the Blue will at least have some 
BA units when Red comes within firing range. However, if 
Blue does not cover the battlefield with his sensors, then 
Red could conceivably attack Blue when Blue only has BU 
units and thereby easily defeat the Blue force. 
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C. THE HOSTILE POECES 



In this simulation the Red units are the aggressor 
force. The Red force is composed of two types of units. Red 
Main (RM) and Red counter-command and control (RCC) . The 
Red Main units only attack the BM forces, ie, BO and BA 
units. The RCC units attack the BC outposts whan they are 
active and withii range. If there are no active, in-range 
BC outposts, the RCC will join the RH force in attacking the 
BM force. 

The RCC units are designed to give the Red force an 
opportunity to ccunter the C2 system of the Blue force. 

They allow the Red force to prevent the Blue force from 
convertina unaimed units to sensor-aimed units by reducing 
the amount of BC resources (BC in equation (4.1)) available 
at a BC outpost. 

I). PRE- BATTLE DECISIONS 

Several command and control (C2) decisions must be made 
by both the Red and Blue forces prior to the start of the 
conflict. 

The Blue force C2 decisions include the following 
factors: 
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1. The "umber of Blue C2 sensor outposts that will 
be deployed (0 to 6) . 

2. The placement of the BC outposts. The Blue force 
should ensure that as much as possible of the battle- 
field IS covered by sensors after considering loss of 
processin c efficiency due to more BC outpost. 

3. The quantity of BC resources allocated to each BC 
outpost. This decision directly affecrs the number 
of units that can be transformed per unit time; it 
also affects the number of fighting units the Blue 
force starts ahe bc'.ttle with. The Blue fighting 
force typically begins with given resources, and 
then, as cssets are placed in the BC outposts, equi- 
valent resources should be deducted from the Blue 
fighting force. Allocation of resources between C2 
and main fighting forces is a crucial decision for 
Blue. 

4. The fraction of a game step during which each BC 
outpost will be turned on. This decision variable 
affects bcth the maximum number of BO units which can 
be converted, and the attrition rate for the BC 
outpost. The longer the outpost is turned on or 
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active the easier it is idsr.tified and targented by 
Red C-C2. 

5. The range of each BC outpost sensor. 

6. The time (BTIME) required by the Blue force to 
react to the hostile action of the Red force. (Many 
of the trade-cffs and issues discussecl earlier should 
be take into account by the user vhen assigning a 
value to this variable.) 

7. The intportance the user places on the distance 
the BC outposts are from both the Red units (RDWT) 
and the Blue fighting units (3WT) . 

a. The placement of the Blue fighting tnits. (This 
decision should be made in conjunction with deciding 
a value for BWT.) 

9. Blue firing doctrine: whether * he BM units will 

fire at only the closest Red unit or will split its 
firing equally among all the targets within firing 
range. 

The Red C2 decisions include the following factors: 

1. The number of Red units which will be designated 
as RCC units. 
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2. Whether or not the RCC will fire on only the 
closest BC outpost, or will divide its fire power 
equally airong all BC outposts within firing range. 

3. The Red counter- comm and and control must also 
decide in advance whether or not it will know if a BC 
outpost's resources have been reduced to zero. If 
the RCC will not know a BC outpost has been elimi- 
nated, then it should continue firing on the 
outpost's position. However, if the RCC will know 
when it has eliminated a BC outpost, then it will not 
need to target that BC outpost any further. 

4. Red firing doctrine: whether the RM force will 

fire only upon the closest BM force, or will divide 
its firepcwer equally among all 3M forces within 
firing range. 

5. Red a ]so has the opportunity to select its route 
of attack and speed of advance. This could enable 
the Red fcrce to stay cut of BC sensor range, or only 
be within sensor range for a short time period and 
attack th€ BM force when it only has unaimed units. 

The ether variables which the user must decide on are 
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1. Weapon characteristics. The user must decide on 
maximum firing range for both Blue and Red weapons 
and the firing rate of those weapons. 

2. Probatility of Kill. The user must assign prob- 
ability of kill's for the Blue unaimed units. Blue 
sensor-ained units, and the Red units. (RiM and RCC 
units have the same probability of kill.) 

3. Hand-to-hand combat range. The user should 
determine a distance at which the opposing forces 
would no longer be able to fire their weapons at each 
ether and would change over to hand-to-hand combat. 

All of the atove decisions can have a direct bearing on 
the outcome of the battle. By varying the above parameters 
and analyzing the results of battles, the user should be 
able to gain valuable insights into the effects of C2 and 
counter C2. 
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V. THE COMBAT HODEL 



Th€ previous section dealt with the C2 process and how 
it affects the forces involved. This section explains the 
combat portion of the computer simulation. It describes the 
attrition calculations for the forces, the differences 
between the dete iministic and stochastic versions of the 
simulation, the tax tie termination and the Red force 
movement . 

A. THE ATTRITIOS CALCULATIONS 

There are two tyces of units represented in this Simula- 
tion, unaimed and sensor-aimed units, and the attrition 
calculations are performed differently for each type of 
unit. However, vihen two forces are firing at each other, 
they are assumed to fire on each other simultaneously. 

1 . U naimed att ritio n C alculat ion 

An unaimed force means there is no coordination 
among the firing units. Ail of the Red force (both RM and 
RCC units) and the Blue unaimed units (BO) have no coordina- 
tion. The expected Red force attrition by Blue unaimed 
units during a game step is found using the following 
eguation : 
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E (K) =RM 




1- (l/EM) (1-(1-BUPK*exp (-RSG) ) ) 



B.?R*STEP 




where 



E(K) = expected number of Red main units killed 



by Blue unaimed (uncoordinated) fire 



RH = the number of Red main units being fired upon 
RNG = distance from the firing 3B units to the 
receiving RM units 

BUPK = Blue unairaed probability of Kill 
BFR = Blue firing rate in rounds per minute 
STEP = number of minutes in a game step 
BU = the number of firing Blue unaimod units. 

The value of the variables RH, BUPK, BFR, STEP, and BD are 
user supplied during the input phase of the sinulation. The 
value of RH and EU change during the course of the battle 
due to attrition and, in the case of 3D, can also change due 
to the transformation from BU to BA. 



Likewise, the expected Blue unaimed attrition by the 



Red Hain units during a game step is found using the 



following equation: 



E (K)=BD 






1-(1/EU) (1-(1-RPK*€Xp (-RNG) ) ) 



BFR*STEP 




where 



E(K) = expected number of Blue unaimed units killed 
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m 

m 



by R€d Main fire 

BU = the number of Blue unaimed units being fired upon 
ENG = distance from the firing RH units to the 
receiving BU units 
RPK = Red probability of kill 
RFR = Red firing rate in rounds per minute 
STEP = number of minutes in a game step 
RM = the number of firing Red Main units 
The value of the variables RM, RPK, RFR, STEP, and 3U are 
user supplied during the input phase of the simulation. The 
Blue sensor-aimed units (BA) attrition is found by subsi- 
tutinq the value BA for BU in equation (5.2). The BC 
outpost attrition is also found by using equation (5.2). 

The value of BC is subsituted for BU, RCC is subsituted for 
RM and the value of RNG is the distance from the firing RCC 
unit to the receiving BC outpost. The rationale for rhese 
expressions is given in Appendix B. 

2 • Aim ed A t trition Ca lc ulation 

The only aimed force in this simulation are the Blue 
sensor-aimed units (BA). The BA units are receiving target- 
ting information from the BC outposts which increase their 
probability of kill. 
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The expected number of Red units killed by 3A during 
a game step is represented as follows: 
if BA/RM<1, then 

E(K) = BA* (1-(1-BAPK*exp(-RNG) ) **BFR*STEP) (5.3) 

or if BA/RM>1, then 

E(K) = SH* (1-(1-BAPK*exp(-RNG) ) ** (BFR* (BA/RM) *STEP) (5.4) 
where 

E(K) = expected number of Red units killed by BA 
BA = number of firing Blue sensor-aimed units 
RM = number of RM units being fired upon by BA 
RNG = distance from the firing BA units to the 
receiving RM units 

BAKP = Blue sensor-aimed probability of kill 
BFR = Blue firing rate in rounds per minute 
STEP = number of minutes in a game step 

Both the equations (5.3) and (5.4) assume that at 
the beginning of the game step each available Red target is 
acquired and there is no opportunity to check for the effect 
of a shot during the game step and change the aim point if 
there was a successful kill. However, checking for kill, 
and change of target, is possible at time step termination. 
(See Appendix B for the derivation of equations (5.1), 

(5. 2) , (5.3) and (5.4)) . 
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B. DETEEHIKISTIC 73 STOCHASTIC VERSIOHS 

The user has the option of selecting either a determin- 
istic or stochastic versi.on of the combat model. The user 
selects the version cf the model by the variance variable 
(line number 4) :n the Table of Variables and Current Values 
(see fiaure 2.2) . If the user sets the variance equal to 
zero, the deterministic version of the model is used. If 
the variance is greater than zero, a stochastic combat model 
is in effect. 

In either version of the simulation, an expected number 
of kills (E(K)) for each type of unit (EM, RCC, 3U, BA, and 

BC) for every ga ae step it calculated from equarions (5.1), 

♦ 

(5.2), (5.3), or (5.4). In the deterministic model, the 

expected number cf kills (l (k)) for each game step is the 
attrition rate for the force. In the stochastic version, 
the expected number of kill? (E(K)) is used as a basis for 
calculating the random artrition rats A+ for the unit. The 
attrition rate A+ is found from the following equations: 

A+ = exp(U + S=s'Z) (5.5) 

where 

U = ln(E(K)) - 0.5(S) 2 (5.6) 

S2 



= VAE*ln (1+1/E (K) ) 



(5.7) 
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VAS = the variance as entered by the user 
Z = is a random number from a normal (0.') distribution 
In fact, the stochastic attrition is governed by a log- 
normal model. (See Appendix C for a derivation of equations 
(5, 5) , (5.6) , and (5.7) ) . 

C. HAND-TO-HAND COMBAT 

Hand-to-hand or "close-in” combat takes place when a Red 
force moves so close to a Blue force rhat neither of the 
forces can fire their weapons at one another. The outcome 
of hand-to-hand combat is determined by the number of forces 
each side has at the beginning of the "close-in” ccraban. 

The force with the largest number of units will win the 
battle. The winning force is reduced in strength by the 
number of units it fought against. For example, if a Red 
force had a total of 90 units (60 RM units and 30 RCC units) 
and a Blue force had a total of 60 units, then after the 
hand-to-hand combat, 30 Red units would have survived. 

(There would be 20 RM units and 10 RCC units.) 

The hand-to-hand combat calculations are as follows: 
if the Red (RT) force outnumbers the Blue (BM) force 
(RT>BM) , then 

RM = (RT - BM)*RM/RT (5.3a) 

RCC = (RT - EM)*RCC/RT (5.3b) 
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BM=BA=BD=0. 0 



(5 . Sc) 



and if the Red (ET) force equals or is outnumbered by the 
Blue (BM) force (RT<BM) , then 



BO 


= (BM - HT)*BO/BM 


( 5 . 9a) 


BA 


= (BM - RT)*BA/BH 


(5.9b) 


RT= 


= RM=RCC=0. 0 


(5. 9c) 



where 

RT = total number of Red units in hand-to-hand combat 
RH = the nunber of RCi units in hand-tc-hand combat 
RCC = number of RCC units in hand-to-hand combat 
BK = total number of Blue units in hand-to-hand combat 
BU = the nuiber of BO units in hand-to-hand combat 
BA = the nunber of BA units in hand-to-hand combat 
The simulation assumes that if a unit is engaged in 
hand-to-hand combat during a game step then it 

1) Can not be fired upon by an opposing force during 
the game step; 

2) The unit can not fire on any other opposing force 
during the game step- 

The hand-to-band combat range is a user supplied vari- 
able during the input phase of the simulation- 
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D. BATTIE TEEHISATION 



The battle is considered over when either all of the Red 
force or all of the Blue fighting force is annihilated. The 
forces can be eliminated either through attrition or hand- 
to-hand combat. 

E. BREAK POINTS 

The user can input a Re d break point and a Blue break 
point. The break points are not utilized during the battle 
itself, but only after it is over, during the interactive 
graphics portion of the program. Break points indicate to 
the user at what point in time the forces would have broken 
off the engagement. The break points allow the user to 
examine what effect breaking off the engagement at that 
point in time would have had on the outcome of the battle, 

P. FORCE H07EHENT 

The present version of the simulation allows the Red 
units the option of movement. The Blue units (both BUI and 
BC outposts) are stationary. The user can choose the posi- 
tion of the BM and BC outposts, but once these positions are 
selected, they remain fixed during the battle. 

The user also selects the initial position of the Red 
units. However, unlike the Blue units, the Red units can 
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move across -.he lattlefield in any direction and ar a user 
supplied speed. The user can specify up to 13 turning 
points at which the Red units change direction. After the 
user has entered Red’s final turning point, the program 
automatically finds the location of the closest Blue Main 
force and ensures that the Red unit will move ro within 
hand-to-hand com tat range of the Blue unit. This feature 
ensures the battle will terminate. 

The method used to calculate the distance a Red unit 
travels and its locaxion is as follows. First, the distance 
the Red unit would move during a game step is found using 
equation (5.10). Then the distance between the Red unit 
(point A in Figure 5.1) and the next Red turning point 
(point B in Figure 5,1) is calculated using equation (5.11). 
If the distance is less than nhe distance calculated by 
equation (5.10), the new coordinates of Red's location are 
found using equations (5.12), (5.13), and (5.14). However, 
if Red would have travelled beyond point 3, the distance 
from point A to coint B is subtracted from the distance 
found in equation (5.10) and the Red unit is moved to point 
B. The distance frcm point B to point C is then calculated 
(equation (5.11)) and compared to the distance the Red unit 
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has left to move. Again, if the distance Ko>5 has remaining 
to move is less than the distance between point B and point 
C, the new coordinates of Red's location are found using 
equations (5.12) , (5.13), and (5.14). This process 
continues until the Red unit has reached its fin.al 
destination. 
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m 




B 

(XB,YB) 




(XA,YA) 



DST 


= SPEED ♦ TIME 


(5. 10) 


LEN 


=y(XA - XB) 2 


+ (YA - YB) 2 


(5, 11) 


ANG 


= t;.n-i (|yb 


- YA|/(XB - XA)> 


(5. 12) 


Xf 


= XS + LEN * 


COS (ANG) 


(5. 13) 


Yf 


= YA + LEN * 


SIN (ANG) 


(5.14) 



where 

Xf and Yf are the final coordinates of the Red unit 

DST = distance a Red unit travels during a game srep 

SPEED = Red speed of advance 

TIME = number of minutes in a game step 

Points A, 3, C are user specified turning points 

Figure 5.1 Red Movement Equations. 
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VI, FOTnRE_BNHMCEMENTS 

After completing the present version of the program, it 
became obvious that several enhancements could be made. 

Some of these improvements will be discussed in this 
sec oion. 

A. TWO-PLAYEB GAME 

The simulaticn could be made into a true two-player 
game. In a limited sense, the present version can be 
considered a two player game since their are two opposing 
forces and one player could make the Blue decisions and the 
other player could make the Red decisions. However, it 
would be a much tetter game and learning experience if both 
forces had the opportunity to have the same type of units, 
ie. Red with command and control outposts and Blue with 
counter-command end control forces. By allowing both the 
Red and Blue forces to have equal capabilities, the combat 
outcome would depend on how effectively a player allocated 
his resources, where he initially positioned his forces, and 
the strategy the player followed during the course of the 
battle. 
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In a true twc-player game, the concepts of secrecy and 
information hiding ccnld be incorporated. The information 
displayed to each player could be made dependent on his 
sensor inputs. In this way, each player would be making 
decisions based cn information obtained from his sensors and 
the accuracy of that information could be a function of the 
amount of resources devotc-d to his sensor system and the 
amount cf resourses his oppcner.t allocaxed to counter- 
command and control, 

B. RE-SUPPLY OF FIGHTING FORCES 

A further improvement would oe to give both the Red and 

/ 

Blue fighting forces an opportunity to re-supply. This 
capability would enable the user to gain insight into how a 
battle could be won or lost through a timely decision on 
when and where xc re-enforce the fighting units. 

This improve rent could be made to the present version of 
the simulation atd ix could be incorporated into the two- 
player game. 

C. NEH TRAHSF0R1!ATI0N EQUATIONS 

A user might also want to develop new, or refine the 
present eguations for transforming BO to BA units. It would 
be interesting to explore the sensitivity of battle results 
to changes in transformation equations. 
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In th€ present simulation, the BA units have a higher 
probability of kill than the BO units. A new transformation 
might possibly increase the firing rate, or decrease the 
attrition rate of the BA units by RH units, or be a combina- 
tion of the three variables — probability of kill, firing 
rate, and attrition rate of BA. 

In this computer program almost any combination is 
possible since all the variables are user defined and -.he 
program’s structure is modular. The user simply writes one 
routine representing his new transformation equation ani 
inserts it in place of the old transformation 7;outine. 

D. DEVEIOPHEHT CF COMBAT SCENARIOS 

A fourth enhancement would be the development of diffe- 
rent combat scenarios to be played out in the simulation. 

The new scenarios might incorporate the forest and cities 
hexes which are cn the playing board but not presently in 
use, or they ndght place restrictions on the two forctf:. 

Having a variety of scenarios would allow the user to 
investigate the effect of command and control in different 
situations. It vould give the user the opportunity to gain 
insights into which parameters are more important (have a 
greater effect) in the different situations. For example. 
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in what kind of combat situation is the decision time of 3 
C2 system most iirportant. One combat situation might be a 
surprise attack, while another would be one in which the 
sensors detect t te approaching opposing forces before they 
opened fire. Or, if the restriction on the Blue force was 
that for every minute under a seven minute command and 
control decision time the fighting force was reduced 50 
units, then how nany fighting units would the Blue commander 
be willing to give up in order to gain the extra time and 
supposedly higher transformation rate for his unaimed units. 
If the Blue commander knew that the opposing force could 
never mount a surprise attack, then the extra time might not 
be needed. In fact, it might be decided to increase the C2 
decision time to 8 or 9 minutes and thereby gain extra 
fighting forces. 

Many different scenarios could be investigated to deter- 
mine the sensitivity of battle results no C2 decisions. 
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APPE NDIX A 



OSER*S MANOAL 

A. IHTRODOCTION 

This computer simulation demonstrates the effect of a 
Command and Control (C2) system on a stylized simple combat 
situation using a simple C2 model. The program is interac- 
tive and user-friendly utilizing high-resolution color 
graphics to display intermediate and end-of-battle resulrs. 

It is hoped that use of this simulation will provide a 
user with iiisights into the effect of C2 upon the outcome of 
conflicts. The user, by varying the amount of C2 and 
counter C2 used during a particular battle, should come to 
understand and appreciate the importance of C2, and how C2 
decisions can easily change the outcome of a battle. 

The purpose cf this manual is to familiarize the user 
with the simulation and user inputs necessary to run the 
simulation. 

3. PROGRAM STHOCrnEE 

The simulaticn is a modular, menu driven program coded 
in FORTRAN. The software can be divided into five distinct 
sections : 
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1) . the aiair. program 

2) . the input section 

3) . the combat section 

4) . the command and control section 

5) . the graphical output section. 

A brief description of all five sections and their major 
subroutines is ircluded in this manual to aid a user in 
understanding the simulation and to allow a user to add new, 
or to improve on the old subroutines. 

1 • Th e !1ain Prog ra m 

The main program, along with the BLOCK DATA module, 
has several important functions. It initializes the RAMTBK 
9400 to accept the graphcial output, calls the major input 
subroutine, the major combat subroutines, the command and 
control subroutires, and the output subroutines for both the 
intermediate and end-of-bat tie displays. 

The simulaticn uses common statements to pass param- 
eters from subroutine to subroutine. The common statements 
are broken down so that only the variables used by a 
subroutine are ircluded in that subroutine. 

The general flew of the program is shown in the 
flowchart in Figure A.1. 
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i START I 




{ Initialize R 
fCALl RH 



AMTEK 9 UOO 
initT 



Initialize program variabres^na flaas 
TIME = 0 
(CAIL INPUT) 

/CALL NODES) 



1 Update position oi 
1 (CALL 


: attacking units" 1 
MOVE) 1 






1 Calculate distance between forces | 
1 (CALL DIST) i 




YES 



ComDuze ^ana-tc- 
hand corabat results 
(C.Al.i. HANT)> 



I 



YES 



Compute a 


ttrit ion 


(CALL 


3LATT) 


(CALL 


SCAT'.?) 


(CALL 


RATTJ 


(CALL 


7T0T1 



YES 



Compute number or 
units transformed 



(CALL C2) 



Upaate t1m3_ 

Save data for snd-of battle analysisp^ 
fCAIL UPDATSi r * 



2nd -of -Batt: 



YES 



NO I 




'Display int€ 


jrmediate Battle results 
[CAIL KLRBD) 

'CALL DISPLY) 
fCAIL 0UT2) 







Display end-cf- 
battle results 
(CALL OUT3) 




Figure A.1 Flow Chart of the Main Program. 
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:no: 

ilhU\ 




2. T he Inp u t Secti on 



There are two major subroutines in the input section 
of the program. The first is the subroutine INPUT. INPUT 
displays the ment titled 'Table of Variables and Current 
Values' and allows the user to change any variable 
displayed. INPUT provides explanations of all the program's 
variables and, if a user decides to change the value of a 
variable, it will insure the new value is within the varia- 
ble's specified range. 

The second major subroutine is NODES. NODES first 
displays the playing board, then draws the approximate 
sensor range for each 3C outpost on the playing board, and 
finally allows the user to enter the Red forces' route of 
attack. The user must use the P.AHTEK's trackball when 
designating the Bed's units attack route. After the user 
has entered the route of attack, NODES ensures that the Red 
force will come to within hand-to-hand combat range of a 
Blue force, thus assuring battle termination. 

3- T he Com b at Section 

The combat section includes force attrition. Red 
troop movement, hand-to-hand combat, and force strength 
update routines. 
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Force attrition calculations are done in three 
subroutines. RATT (Red attrition) calculates the expected 
number of Red units killed by the Blue units. 3LATT (Blue 
attrition) calculates the expected number of Blue Main units 
killed by the Red force. The third subroutine 3CATT (BC 
outpost attrition) calculates the expected loss of BC 
resources to RCC fire. In the routine FTOT, the true attri- 
tion rate for the forces is calculated. If the 
deterministic model is in effect, then the true attrition 
rate is set equal to the expected number of kills calculated 
in RATT, BLATT, and ECATT. However, if the stochastic 
version of the model is in effect, then the true attrition 
rate is calculated using a log-normal distribution. 

The Red troop movement is performed by the routine 
MOVE. The routine MOVE moves the Red force along the route 
selected by the user. The routine HAND calculates the 
results cf all hand-to-hand combat. And finally, the 
routine UPDATE saves the data needed by the routines which 
display the end- cf- battle results. 

^ • T he Com m and and Co n trol Sec tion 

There are three main routines used by the command 
and control section. The three routines are DIST, C2, and 
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CHANGE. DIST calculates the distance between all the uni^s 
on the playing beard. The range between units is used in 
all attrition calculations, and also in the transformation 
calculations. Fcr each BC outpost, the routine C2 calcu- 
lates the maximuB number of DU units to be transformed to BA 
units during a game step. The routine CHANGE takes the 
output of the C2 routine and for each Blue Main force calcu- 
lates the actual number of 3U units transformed to BA units. 

5. T he Gra phical Outp ut Sec ti on 

There are twe distinct graphical output displays. 

The first is the intermediate battle results which are 
displayed at end of every game step. This display is built 
be several subroutines. The subroutines include BOARD, 
POTMEN, DELETE, CISPLY, LTH3ZE, CLRBD , and several minor 
routines. The fcrce status reports shown at the bottom cf 
the display are generated by the routines OOT1 and 0UT2. 

The second graphical output is the Force Strength vs 
Time plots. These graphs are generated by the routine OOT3 
and displayed after combat terminates. 0UT3 calls several 
minor routines which draw the axis (3AXIS) , scales the data 
(BSCALE) , draws the break points for the forces (BRKPT) , and 
connects the data points with a continuous colored line 
(BLINE) . 
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C. THE INPUT DATA 



Prior to running the simulation, the user musn 



initialize the variables listed in the menu titled 'Table of 



Variables and Current Values'. To aid the user all the 
variables have been given default values. To change a vari- 
able's initial value, or to obtain an explanation of rhe 
meaning of the variable, the user simply enters the line 
number associated with that variable. For example, rbe line 
number associated with hand-to-hand combat range is 6- 
After entering a 6, the user would receive an explanation of 
hand-to-hand combat range and then have nhe option of either 
changing its present value, or leaving it unchanged. 

The following is a list of all the variables, their 
associated line rumbers, default values, and an explanation 
of the meaning of the variable. 

Line Variable 

Numbe r De fau lt V alu e Explan ation of V aria ble 

1 Number cf Red Forces The number of active Red 



Default : 2 



forces. Each Red force 



consists of RM and RCC 



forces. There can be 



either 1 or 2 Red forces 



2 



Number cf Blue Forces The number of active BM 



Default: 2 



forces. Can have 1, 2, 
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or 3 forces 



3 Number cf Blue Sensor 


The number of active EC 


Outposts (BC) 


outposts. Can have 0 to 6 


Default : 2 


BC active during a battle 


4 Seed 


Used to generate a random 


Default : 12345 


number. Should be an 
integer from 0 to 99999. 


Variance 


If variance=0. 0 , then a 


Default : 1.0 


deterministic model is in 
effect. If variance>0. 0, 
then stochastic model is 
in effect. The variance 
indicates the magnitude 
of variation in the 
attrition rate. 

The range is between 0.0 
and 10.0. 


5 Time Step (Min) 


The duration in minutes of 


Default : 10.0 


each engagement. Range 
should be from 1.0 to 99.0 
minutes. 


6 Hand-to-Hand Combat 


Distance at which forces 


Range (KM) 


change to hand-to-hand 
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Default: 0.25 


combat. The range should 
less than 1.0 KM. 


7 Red Firing Bate 


Number of shots fired per 


(rou nds /min) 


shooter per minute by rhe. 


Default: 5.0 


RED forces. Range shculd 
be from 1.0 to 10.0 shots. 


3 Red Maximum Firing 


Distance at which Red 


Range (KM) 


forces open fire. Range 


Default: 3.0 


should be from 0.0 to 10.0 


9 Red Protability of 


Probability of kill for 


Kill 


each shot fired. Range 


Default: 0.40 


should be from 0.0 to 1.0. 


10 Red ;>peed of Advance 


Speed at which Red forces 


(KPH) 


move across the battle- 


Default: 3.0 


field. Range should be 
from 1.0 to 10.0 KPH, 


11 Red Mair Split 


If YES, then RM units 


Firing Allowed 


will fire on all targets 


Default: YIS 


within range. If NO, then 
RM will only fired on 
closest BM force. 


12 RCC Split Firing 


If YES, then RCC units 


Allowed 


will fire on all BC units 
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Default: YES 


within range. If HO, then 
RCC will fire on only 
closest BC outpost. 


13 RCC will fire at only 


If YES, then RCC will only 


non-zerc BC outpost 


fire at BC outpost which 


Default : HO 


have not been eliminated, 
BC which have resources 
greater than zero. 

If NO, then RCC will fire 
at all identified BC 
outpost. Even those which 


• 


have had their resources 
reduced to zero. 


14 Red Men and Location 


The number of RM and RCC 


Default : RM1 = 90 0, 


units initially active in 


RCC1 = 900, X = 8.0, 


the first Red force and 


Y = 3.0 


the:.r initial location. 
RK and RCC should from 0 
to 10000. The X and Y 
coordinates should be 
between 0.0 and 10.0. 


15 Red Men and Location 


The number of RM and RCC 


Default ; RM2 = 90 0, 


units initially active in 
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RCC2 = 100 , X = 7. 5, 
Y = 1.5 



16 Red Break Point 

Default: 0.70 

20 Blue Filing Rate 

(rounds/min) 

Default : 5.0 

21 Blue MaximuE Firing 

Range ( KM) 

Default: 3.0 

22 Blue Speed of Advance 

Default : 0 . 0 

23 Blue On aimed Probabili 

of Kill 

Default: 0.25 



the second Sad fores and 
their initial location. 

RM and RCC should from 0 
to 1C000. The X and Y 
coordinates should be, 
between 0.0 and 10.0. 

The percent of losses 
of Red's initial strength 
at which Red would retnsat 
Should be less than 1.0. 
Number of shots fired per 
shooter per minute b'j the 
Blue forces. Hangs should 
be from 1.0 to 10.0. 
Distance at which Blue 
force open fire- Hangs 
should be from 1.0 to 10.0. 
Speed at which the Blue 
forces move. Not used in 
version of the simulation, 
ty The probability of kill 
per shot of the BO units. 
Must be from 0.0 to 1.0. 
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24 



25 



26 



27 



28 



Blue Sersor-Aimed 
Probability of Kill 
Default: 0.70 

Blue Split Firing 
Allowed 
Default: YZS 



Blue C2 Decision 
Time (MIN) 
Default: 5.0 



Blue Men and Location 
Default: BUI = 800, 

X = 4. 0 , Y =4.0 



Blue Met and Location 
Default : BD2 = 80 0, 



The probability of kill 
per shot of the BA units. 
Must be from 0.0 to 1.0. 

If YES, then BH units will 
spread its fire equally 
among all Bed within 
range. 

If NO, then BM units will 
fire on only the closest 
Red force. 

The time required by the 
Blue forces to respond to 
the Red hostile action. 

The range should be from 
0.0 to 99.9 minutes. 

The number of Blue unaimed 
units initially active. 

3U should be less than 
10000. The X and Y coor- 
dinates should be between 
0.0 and 10.0. 

Same as line 27. 
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X = 3. 5 , Y =6.5 



30 Blue Br€ak Point 

Default: 0.50 



40 Red Range Weight 

Default : 2.0 



41 Blue Ear.ge Weight 

Default: 10.0 



42 BC outpost Force, 



The percent of losses of 
Blue's initial strength 
at which Blue would 
retreat. Should be less 
than 1.0. 

The importance of the 
distance from the Red 
force to the reporting BC 
outpost. Should range 
between 1.0 and 10.0 where 
1.0 means the most impor- 
tant factor and 10.0 means 
the least important factor 
The importance of the 
distance from the Blue 
force to the reporting BC 
outpost. Should range 
between 1.0 and 10.0 where 
1.0 means the most impor- 
tant factor and 10.0 means 
the least important factor 
For each BC outpost the 
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to Sensor Bangs, Time on 

47 per Gaai€ Step, and 

Positio r. 

Default : BC1 = 30 0, 

Sensor Fange = 3.0, 
Time on = i.O, 

X = 5.5, Y = 4.5 
3C2 = 300, 

Sensor Fange = 3.0, 
Time on = 1.0, 

X = 6. 0 , Y = 6. 0 



The user indicates to t 
initializing the variables 
After entering 9S, the user 
attack. Entering the attack 
the user through the use of 
user designates all turning 
cursor to the hex where “he 



initial amount of 
resources (force) 
allocated to the outpost, 
its maximum sensor range, 
the percentage of a game 
step the outpost is active 
and its position. Initial 
unit strength should be 
less than 9999. 

Maximum sensor range 
should be between 1.0 and 
10.0. Time on should be 
between 0.0 and 1.0. 

The X,Y coordinates should 
be between 0.0 and 10.0. 
he program that he has finished 
by entering a 99 at the keyboard, 
can select the Bed route of 
route has been simplified for 
the SAHTEK's trackball. The 
points by moving the trackball 
turning point is to occur and 
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depressing the enter key on the trackball. The user can 
designate a maxinum cf 13 turning points for each Red unit. 
The Red force will travel in a straight line from turxiing 
point to turning point. When the desired path of the Red 
force has been entered than move the cursor into the red 
area at the bottom of the screen and depress tha enter key 
on the trackball. 

On the second and all subsequent runs, the user is given 
the option of entering a new route of attack or using the 
previous route of atrack. If the usar selects to use the 
previous route of attack, the Red force will start and 
finish at the saae location as in the last run. Tharefora, 
the user should rot change the X or I coordinates of either 
the Red force or the Blue force when sleeting to use the 
attack route of the previous run. 

D. OOTPOT 

There are two distinct high- resolution graphical 
displays used by the simulation. One is the playing board 
displays which indicate unit position and strength at the 
end cf each game step and provide one cf four different 
status reports at the bottom of the screen. The other is 
the Force Strength vs Time plot which is available to the 
user at the end cf a conflict. 
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1 • Pl aying Eoard Displays 

Figures 2.5, 2.6, 2.7, 2.8 ace examples of playing 
board displays. Each picture shows the same point in time 
of a battle but a different status report is displayed at 
the bottom of the screen. The user selects the starus 
report desired by placing the trackball cursor over the 
letters representing the status report and depressing the 
enter key. For example, to view the Blue Force Status 
report the cursor is placed over the word 'BLUE' and the 
enter key is depressed. To examine the BC Outpost Status 
report the cursor is placed over the letters 'BC* and the 
enter key is depressed. When the user places the cursor 
over the word 'HCDEL' and depresses the enter key, the posi- 
tion and strength of all the forces for the next game step 
is displayed on the playing board. 

2 . Fo rce S tren gth v s T ime Plots 

At the erd of a battle, the user can build graphs 
such as the one shown is Figure 2.9, To build a graph, rhe 
use selects a force to be plotted. For example, to plot the 
Blue total fighting force strength (5T1) vs time, the user 
places the cursor over the letters BT1 and depresses the 
enter key. A plot of force strength vs time will be made 
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for t he 



first Blue Main force. Spaced along the line will 



be the letter in parenthesis next to the force selected, in 
this case the letter G. This feature allows the user to 
distinguish between lines of the same color. (The Red 
forces have red lines and letters; the Blue fighting forces 
have blue lines and letters; the BC outposts have black 
lines and letter?.) Break points (a user input) are shewn 
on the total force strength lines only {5T1, RT2, BT12, BT2, 
BT3) . Break points enable the user to hypothesize what 
would have happened had the units retreated upon reaching 
their break point. 

To clear the screen and replot a force, the user 
places the cursor over the words 'NEW PLOT' and depresses 
the enter key. To terminate the plotting routine and return 
to the beginning of the next simulation run, rhe user places 
the cursor over the word 'RETURN' and depresses the enter 
key . 

There is a maximum of 50 data points per line which 
can be plotted ir this routine. Therefore, if a battle 
simulaticn has mere than 50 game steps, only the first 50 
data points will be plotted. 
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E 



TO EOS THE SiaOiaTION 



The simulaticn program is located in Spanegle Hall room 
500 on the POP 1 1/50 computer system. To run the simula- 
tion, the user must do the folloviing; 

1) . Turn on the RAMTHK 9400. The OVOFF switch is 
located on the. front panel of the EAMTEK 9400 cabinet. 

2) . Turn on the EAMTEK 9400 keyboard, trackball, and 
color monitor. All of the ON/OPF switches for these 
devices are clearly marked on the front of each device. 

3) . Log on to the POP 11/50 system at any terminal 
located in the room. The commands are 

>HEL BENT 
> pass word: BENT 

(a system message is displayed) 

>RUN BENT 

(Note that the > sign is a system prompt and that the 
user only tyjes the letters that are capitalized. The 
lower case letters are displayed to the srceen by the 
PDP 11/50 operating system.) 

4) . After entering RUN BENT, the user must use the 
EAMTEK keyboard and trackball to communicate with the 
simulation. The program is interactive with step-by- 
step directions provided for the user. 



82 



5). After the last simulation run, the user should log 
off the syst€m by entering the following command at the 
terminal at which he logged on 
>BYE 

To obtain a copy of the source code, the user should 
enter the following command prior to logging off the sys'cem 
>3PRNT 
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APPENDIX B 

•DERIVATION OF ATTRITION EQOATIONS* 

Suppose a Blue force confronts a Red Force. Further, 
suppose that Blue attacks Red and doss so without coordina- 
tion (command anc control) , ie, each B in Blue picks a 
member R in Red at random and fires at it independently of 
the actions of the other B's in Blue. Assume that all Rs in 
Red are equally likely to receive firs from a single B. 

Also, assume that the kill probability of B against R is 
given by the expression 

Pb = Pw * exp(-EANGS) (3.1) 

where RANGE is the distance between the firing B and the 
receiving R and Ew is the probability of kill for the weapon 
fired. Further, let denote the firing rate of B. 

Let K denote the random number of Rs killed by the Bs 
per engagement ( cf duration ^). Then during the engagement 
of time the E fires shots. The number of Rs 

killed, K, may be expressed as 

K = 1(1) + 1(2) + ... + I(j)+ ... + I(r) (B.2) 

where R is the number of Rads receiving fire during the 
period, and the indicator random variable 
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f 1 if tha jth R is killed by B fire 

-<’> = [o 



otherwise 

then the expected number of kills, E{k), is 
R 

E{K) = 2E(i(j)) = 3*E(I(1)) = R*P(I(j)=1) 

1 = 1 



(B.3) 



where P(I(i))=1) is the probability of at least one kill 
during the er.gagirent duration ^ , assumed to be the same 
for each element of the Red force. If E (I (i) ) can be 
computed, then E (K) can be found. 

First of all, it should be noted that the probability 
that i of the B’ s targat the jth R is given by the binomial 

i B-i 

B\ (1/R) (1-(1/R)) , i=0, 1, 2, . . . ,3 (B.4) 



Then, given that a B is targeted on the jth R, the prob- 
ability of at least cne kill in an engagement of duration 



IS 



1 - (1 - Pb) ^ ^ 

Therefore, the piobability of at least one kill by i B*s 
firing independently is 

y \ i i 

1 - ((1-Pb) ) = 1 - Z (B.5) 

where Z is the piobability of no kills per engagement wi~h 



one B. Now, 



B 



S i /B\ i B-i 

^ (1- Z ) UJ (VR) (1 - (1/S) 
i=0 
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B 

= 1 - (Z * (VB) ! - (1/R)) (B.6) 



Since E(I(i)) = E(I(i)=1), then 

E(I(i)) = 1 - (1- (1/R)* (1- ^ (B.7) 

Then from equation (B,3) , 

*y \ B 

E (K) = R*(1 - (1 -{1/R)*(1- (1-Pb)^ ^'')) (B.8) 

Equation (B.3) is Equation (4.2) which is used in the 
computer simulation to find the expected number of kills 
from unaimed fired. 

When B is firing on R with coordination, the experssion 
for E (K) becomes 



E(K) = 3*(1 



(1-Pb)' ^) 



for 5/R<1 



(3.9) 



and 

/ y X(B/R)\ 

E(K) = R* I 1 - (1-Pb) j for (B/R)>1 (3.10) 

Equation (B.9) assumes that one 3 per R is allocated for as 
long as the B's last. Equation (3.10) assumes that (3/H) 
B'S are allocated to each R during the engagemenr. No 
account is taken of the fact that 3/R is often not an 
integer. 

Equation (B. 9) and (3.10) are the aimed attrition equa- 
tions of Chapter IV. 
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APPE NDIX C 



DEHIVATICN OF THE STOCHASTIC ATTRITION RATE 



Assume that F(t-1) represents the size of the Rea force 
at the (t-1) step in time. Let A+ be the stochastic attri- 
tion rate of the Red force by the Blue force at the t srep 
in time. Let Or (t) be equal to the expected number of kills 
(E(k) ) of the Red force by the Blue force found by using 
equations (5.1), (5.3), and (5.4). An equation for k*- will 

now be developed based on a log-normal distribution. 

For a log-noimal distribution 



where 

Z is a random variant from a normal (0,1) distribution 
0 is the mean 

S is the standard deviation 
The expected value of X is 



X = exp (U + S*Z) 



(C- 1) 



E (X) = S (exp (0 + S*Z) ) 



exp (U) * S (exp (S*Z) ) 



but 




Therefore, 



E (X) = exp (0 + 0. 5 *S 2 ) 



(C-2) 
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If the expected value of X, E(X ) , is equal to the expected 
number of kills 6r(t) of the Red force, then 
E(X) = 6r(t) 

and 

©r (r) = exp (U + 0. 5*S2) 

In (0r (t)) = U + 0. 5*32 
and therefore, 

0 = ln(er(t)) - 0 . 5*32 (C-3) 

The variance of X is 

VAR (X) = E (X2) - (E (X) ) 2 

Now E(X2) = exp(2U + 232) 

and (S (X) ) 2 = exp (2U + 32) 

Therefore, 

VAR(X) = exp(2U +232) - exp(2U + 32 ) 

= exp(20 + 32)*{exp(32) - 1) 

= (E(X)) *(exp(32) - 1) 

For a Poisson Distribution, 

VAR(X)/E(X) = 1 

Therefore, assuming Poisson variability in kills, 

1 = E (X )* (exp ( 32 ) - 1) 

and if 6r(t) = I(X), then 

1 = Gr (+) * (exp ( 32 ) - 1) 

(exp (32) - 1) = 1/0r (t) 
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S 2 =r In (1 + V©r (t) ) (C-4) 

and when VAE(X)/E(X) * 1 

then 



S2 = VAE(X)*(ln 1 + 1/er(t)) 



(C-5) 



and 



S = SQRT(S2) (C-6) 

Finally, let A+ be equal to X in equation (C-1) and then 
A+ = exp(U + S*Z) (C-7) 

where 

U is the mean found in equation (C-3) 

S is the standard deviation found in equations (C-5) and 
(C-6) and 

Z is a random vcriate from a normal (0,1) distribution 



89 



BI3LI0GEa?Hf 



Gaver, Donald, P, "Hodsls that Reflect rb.e Value of 
Information in a Command and Control Context," Naval 
Postgraduate School Technical Report NFS-55-80-027. 



Lawson, J, S. "The Role of Time in a Command Control 
System", Naval Electronics Sysrem Comnand. Washington, 

D.C. 



Lawson, J, S. "Command Control as a Process". Naval 
Electronics System Command, Washington, D.C. 



RM- 94 00 F ORTRAN Int e rfac e P acka ge iFIPl,^ Santa Clara, 19 80. 



Tongue, K. a od elina the Effect of Info rma tion on Co nf l ic t 
Outcome. M.'S, T'Resis, Naval Postgraduate ScHocI, Honrerey, 
rallrornia, 1979. 



90 



IHITIAL DISTRIBUTION LIST 



No. Copie 

1. Defense Technical Information Center 2 

Cameron Station 

Alexandria, Virginia 22314 

2. Library, Code 0142 2 

Naval Postgraduate School 

Monterey, California 93940 

3. Professor D, P. Gave?, Code 55Gv 2 

Department cf Operations Research 

Naval Postgraduate School 
Monterey, California 93940 

4. Capt J. E. Pent 2 

HQ ECD/DCXRC 

APO New York 09012 

5. Professor J. G. Taylor, Code 55Tw 1 

Department cf Operations Research 

Naval Postgraduate School 
Monterey California 93940 

6. Professor J. M. Wozencraft, Code ^2Wz 1 

Department cf Electrical Engineering 

Naval Postgraduate School 
Monterey, Califcrnia 93940 

7. Professor P. H. Moos^, Code 62Me 1 

Department cf Electrical Engineering 

Naval Postgraduate School 
Monterey, Califcrnia 93940 

8. CDR Gary Porter, Code 55Pt 1 

Director C2 Warlab 

Naval Postgraduate School 
Monterey, Califcrnia 93940 

9. CDR Adams 1 

Center for War Gaming 

Naval War College 

Newport, Rhode Island 02340 

10. Naval Electronics System Command 1 

Dr. J. Lawscn 

Washington, D.C. 20360 

11. Ccmmander-i n-Chief Pacific 1 

Command, Code 577 

Camp Smith, Hawaii 96861 

12. D.S. Army War College 1 

capt Howard Yellen, USA 

Carlisle Barracks, Penn 17013 

13. Professor M. Sovereign 1 

Chairman, Cede 74 

C3 Academic Group 

Naval Postgraduate School 

Monterey, California 93940 



91 



16 



Thesis 

B3917 

C.2 




Bent 

A computer simulation^^ 
of a combat model which 
uses command and con- 
trol. 



2A APR 87 - - 3 2 0 4 6 



Thesis 

B3917 

c.2 



Bent 




A computer simulation ■. 
of a combat model which 
uses command and con- 
trol. 



thesB3917 

A computer simulation of a combat model 




3 2768 001 03734 4 
DUDLEY KNOX LIBRARY 



